It's written this way in case np.any has an early return condition once it detects a single non-NaN value

np.all can have the same early stopping

Well, interesting results...

Indeed as you say, all does indeed have early stopping just like any...

nelems = 1000000
array1 = [True for _ in range(nelems)]
array1 += [False]
array2 = [False]
array2 += [True for _ in range(nelems)]
start = time()
all(array1)
runtime = time() - start
print(f"Took {runtime}s!")
start = time()
all(array2)
runtime = time() - start
print(f"Took {runtime}s!")

----------------------------------

Took 0.006882190704345703s!
Took 3.719329833984375e-05s!

... however numpy does not appear to (likely because it's vectorized). Maybe that gives better performance for very large in-memory arrays, but for sparse inputs the early return from Python built-ins might be nicer.

nelems = 1000000
array1 = [True for _ in range(nelems)]
array1 += [False]
array2 = [False]
array2 += [True for _ in range(nelems)]
start = time()
np.all(array1)
runtime = time() - start
print(f"Took {runtime}s!")
start = time()
np.all(array2)
runtime = time() - start
print(f"Took {runtime}s!") 


----------------------------------

Took 0.05324196815490723s!
Took 0.05084705352783203s!

By sparse do you mean short?

Either approach is fine with me, either using all or np.all.

I guess 'sparsity' (% of the number of False items being passed into all) isn't as relevant - I just mean for any case where there is at least one False element occurring somewhat early on in the input to all (as opposed to occurring later in the vector, as seen above), it will exit a few ~ms faster per check (which could add up to seconds when streaming over an entire dataset).

Anyway, I implemented the all logic here.